home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_0399
/
255
< prev
next >
Wrap
Text File
|
1994-08-27
|
4KB
|
118 lines
Subject: Re: Shortcut Manager
Date: Thu, 2 Jun 1994 14:12:45 +0200 (MDT)
In-Reply-To: <memo.262762@cix.compulink.co.uk> from "Andre Willey" at Jun 1, 94 04:24:00 pm
From: Annius.Groenink@cwi.nl (Annius Groenink)
X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
Mime-Version: 1.0
Precedence: bulk
> Better still (and trying to avoid over-thinking the plumbing, if possible)
> how about a system text file, rather like ASSIGN.SYS, NEWDESK.INF, etc,
> which contains the user's preferred shortcuts. A default file could be
> created which pretty much mirrors the contents of our final standard - or
> indeed *is* the final result of our work? The user could then change their
> own local copy as required - for example to allocate 'Select All' to some
> other key sequence. :-)
Yes. Let's first define a standard for such a file, and then continue
our discussion of the shortcuts in the formalism put forward.
Let's continue as follows: we'll talk about what exactly we want in the
KEYBIND.INF file, and what not. Then after a few days, based on the
results of that discussion, I will put forward a definition of the file's
syntax, trying to match
1) The results of the discussion
2) Some other existing standard (Xdefaults style or even better,
something existing on Atari) so that people only need to learn
as little as possible.
We will also define a preferred way of interpreting the file. Then
after I have submitted the prototype definition and semantics, you guys
pull it down again (in a constructive sense). How does that sound?
> Each application which supported this new system would simply read the text
> file during its installation process, and pick out any shortcuts that it has
> a use for.
And if we decide to write a resource manager some day, then the programs
which simply read the file are still fine, but the more modern programs
that use the resource manager are better off, as they don't need the
algorithms to read the file and choose the binding which suits them most.
> For example, a small section of this proposed SHORTCUT.INF file:
> 0 ^Q ; Quit
> 1 ^A ; Select All
> 2 ^W ; Cycle Windows
In a very simple formalism. I'm convinced that we need to separate
codes into default sections, class dedicated sections and
application-specific codes.
> The code numbers at the start of each line would be defined as part of our
> spec, and used by each application to determine what type of command is being
> defined on each line. The comment after the ';' would thus be for user-
> information only, and could be in any desired language - the code and the
> keypress are all that would be needed to parse the file.
I think we shouldn't use 'codes'. Your formalism looks too much like
ASSIGN.SYS, which IMHO is hard to grab for a naive user (it is hard enough to
understand for me!)
We can start compiling a list of actions now, I should think.
Examples (case INsensitive)
New
Open
Close
Close-Top (different for applications that allow
mouse-based keyboard focus)
Save
Save-As
Print
Quit
Undo
Redo
Cut
Copy
Paste
Delete
Cut-Line
Delete-Line
Select-All :-)
Cursor-Right
etc.
Cursor-Word-Right
etc.
Cursor-Line-Home
Cursor-Line-End
Delete (problem: what to do at end of line?)
Backspace (problem: what to do at beg of line?)
Delete-Word
Backspace-Word
Delete-to-Line-Home
Delete-to-Line-End
Sorry, I'm getting tired.
--
Annius V. Groenink | E-mail: avg@cwi.nl | Private & ZFC:
CWI, Kruislaan 413 | Room: M233 | P.O. Box 12079
1098 SJ Amsterdam | Ext: 4077 | NL 1100 AB Amsterdam
Netherland | Phone: +31 20 592 4077 | Phone: +31 20 695 9901